This invention relates generally to network address translation and, more particularly, relates to generalized network address translation under application program control.
As the number of computers that needed or wanted to be connected to the Internet continued to grow, it soon became obvious that this number could not be accommodated by the number of available IP addresses, known as dotted-quads. In response to this address depletion problem, a method as illustrated in FIG. 2 was devised whereby a number of computers C1, C2, etc. could be located on a xe2x80x9cprivatexe2x80x9d network 60 and would use private IP addresses 62 to communicate with each other. These private IP addresses could be reused on other private networks since no one outside the private network could see these addresses. In order to allow the computers on the private network to communicate with other computes S1, S2, etc. on a public network, such as the Internet 64, the private network utilizes one machine 66 to provide the gateway for all of the computers on the private network to reach the public network. Through the use of the private addresses 62 on the private network 60 and the gateway computer 66, the address depletion problem is at least slowed.
This gateway computer 66 runs a program called a network address translator (NAT) that has both a private IP address 62 and a public IP address 68. As computers on the private network attempt to establish sessions with a server on a public network (or another private network), the NAT changes the source address 70 of the message packets 72 from the private address of the client computer to its public IP address. In this way, the private IP address is not communicated on the public network. The messages all appear to have come from the public IP address of the NAT machine. The NAT maintains a mapping 74 of the translation from the private to the public IP address so that when messages are received from the public network in response as illustrated by line 76, the NAT can forward them to the proper client machine. This operation of the NAT is completely transparent to the client computers on the private network, i.e. they each believe that they are communicating directly with the public servers.
FIG. 3 illustrates this redirect capability of the NAT machine. Specifically, a client machine C1 attempts to establish a session 78 directly with public server S1 as indicated by dashed line 80. However, when the message from C1 is detected by the NAT 66, it dynamically redirects 82 the message to S1 and changes the source address as described above. The client process does not know that the NAT has changed its messages"" source address, and continues to believe that it is communicating directly with the public server. Messages from the server S1 are dynamically redirected 82 to the client C1 based on the mapping of the address translation. As may be seen from FIG. 4, this address translation takes place at a low level, e.g. at the kernel level 84 in a Window""s architecture.
While the NAT has greatly alleviated the address depletion problem, especially for home and small business networks, its translation of source addresses is fixed within its programming. That is, the traditional NAT does not allow any application control of the address translations that it performs. Additionally, since the address translation is performed on the message packets at such a low level within the kernel 84, the NAT can add almost no value, other than providing the raw source address translation. The NAT cannot even provide any destination address translations. If added value is desired, such as centralized virus scanning, site blocking, white listing, etc., a proxy must be used instead.
Traditional proxies, as illustrated in FIG. 5, are application programs existing in the user mode 86 that serve as the interface between the private 60 and the public 64 network (see FIG. 6). Unlike NATs, the proxy 88 must be addressed directly by the client machines as seen in the destination address field 90 of message packet 92, and therefore requires that the client applications C1, C2, etc. be setup to operate with a proxy 88. Many applications cannot do this, or require specific configuration changes to allow the use of a proxy, and therefore a proxy configuration may not be appropriate for all applications. When a proxy application 98 is used, all communications are sent to the proxy in the user mode 86 (see FIG. 5) as illustrated by lines 94, 96. The proxy 98 then determines whether and to whom to forward the communication on the public network. If the proxy determines that the message may be passed to a server on the public network, the proxy establishes a second session 100, copies the data to the second session, changes the source and destination address, and sends out the message (see, also FIG. 7). In operational terms as illustrated in FIG. 7, a client process C1 establishes a first session 94 with the proxy 88 requesting access to a public server S1. If the proxy agrees, a second session 100 is established with the server S1 on the public network 64. Since all messages must pass from the kernel-mode network transport, e.g. TCP/IP 102, to the user-mode proxy 98, be copied to a second session, transferred back down to the kernel-mode driver 102, and finally transmitted to the network for the network application""s other session, a significant performance degradation occurs.
The instant invention overcomes these and other problems by providing an application programming interface for translation of transport-layer sessions. Specifically, the inventive concepts of the instant invention relate to a generalized network address translator (gNAT) and associated application programming interface (API) that allow both source and destination address translations to be made under application program control. This allows value to be added to the address translation. Additionally, it significantly increases the data flow speed over a traditional proxy since there is no longer a requirement that all information received at the kernel-mode be passed to the user-mode, copied to a second session, and passed back to the kernel-mode for transmission.
With the generalized NAT (gNAT) of the instant invention and its associated API, both the source and the destination addresses of message packets may be changed. The address changes are mapped in the gNAT, and may result in apparent sessions between different clients and servers. Depending on the protocol in use (e.g. TCP or UDP), the address translation may be made dynamically by the gNAT, under the command of the application, and take place at the kernel level. This significantly improves the data flow of the system by short-circuiting previously required data transfer between the kernel and user modes.
As discussed above, data transfer through a traditional proxy (a user-mode application) requires that the incoming messages from a client on a first session be transferred from the kernel-mode to the user-mode so that the proxy can deal with them. The proxy then would copy the message to a second session, and pass it back down to the kernel-mode for transmission to the server. Likewise, information from the server would arrive at the kernel level, be transmitted up to the user-mode for processing by the proxy, be copied to the other session, and be transmitted back down to the kernel-mode for transmission back to the client. Significant transmission delays were incurred as a result of all of these kernel-to-user-mode transitions.
The system of the instant invention eliminates, or at least greatly reduces, this overhead performance degradation while still adding value to the communication. Specifically, once the application, in this case a proxy, determines that a second session will be established (or a data session), it can command the generalized NAT through the API to perform an address translation at the transmission layer (kernel-mode), and therefore eliminate the transitions between kernel and user modes. The generalized NAT receives the incoming message from the client, confirms that it has a mapped translation, performs the address translation, and passes the message along to the server. Since this translation occurs at the kernel level, the data transfer performance is greatly improved.
Since the generalized NAT and associated API of the instant invention allows for destination address translation of a message packet, another advantage provided by the instant invention is server load balancing. This balancing is achieved by a server load control application that utilizes the gNAT through its associated API to command address translations away from heavily loaded servers to servers with more available capacity. Dynamic load balancing is also possible, dependent on the communication protocol used for the session. That is, a TCP session continues to address all message packets to a server once assigned thereto since the TCP protocol is connection oriented. UDP messages, on the other hand, may be dynamically redirected to an available server at the time of message delivery since UDP is message oriented.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying figures.